Invention relates to communications, particularly to inter-working between disparate access and destination protocols.
Reliable, high quality telephone service and custom call features such as call forwarding, call waiting and three-way calling have become indispensable business tools. These services are commonly provided by Incumbent Local Exchange Carriers (ILECs) using expensive switches known as xe2x80x9cclass 5xe2x80x9d switches that are located in central offices (COs). FIG. 1 illustrates an example of a typical switched circuit Public Switched Telephone Network (PSTN). An ILEC may provide both voice and data services to both small and large business customers using their legacy infrastructures. With typical legacy equipment, an ILEC, may provide voice services using a circuit-switched model where a typical resource unit is a 64 Kb/s circuit allocated on a one-for-one basis. In contrast, many Competitive Local Exchange Carriers (CLECs) focus on providing services over broadband networks such as Digital subscriber Lines (DSL), cable and wireless that are optimized for data transmission. With a typical CLEC, data services may be provided using a packet-based network where bandwidth efficiency may be increased. While voice services may be offered over packet-based networks, the quality of these voice services tends to be compromised in typical implementations that do not support quality of service (QoS) methods. Furthermore, profitably providing high quality telephone services and a comprehensive selection of custom call features to a variety of small and large customers has proven to be challenging for most CLECs. This is due, in part, to the complex translations and mappings that must take place to interwork between the different protocols involved.
For example, instead of implementing expensive class 5 switches to provide both data and voice services to their customers, a CLEC may choose to provide these services by establishing a gateway to the PSTN class 5 switches. This gateway may inter-work between the access protocols and the destination protocols. One approach is to use inter-working functions in conjunction with or instead of gateways. For example, the ATM Forum document xe2x80x9cLoop Emulation Service using AAL2,xe2x80x9d af-vmoa-0145.000, July, 2000 describes inter-working between specific protocols, AAL2 to GR-303 and AAL2 to V5.2, using multiple inter-working functions. In some cases, these techniques may be used to reduce overhead and gain a competitive advantage over the CLECs by treating both voice and data traffic as data traffic and packetizing all traffic. However, using gateways and/or typical inter-working functions that may inter-work between specific access protocols and specific destination protocols may not provide sufficient flexibility. Adding flexibility to their service offerings, such as adding support for a new access protocol, or new capabilities such as dynamically choosing the most cost-effective transmission media, may require buying new equipment, such as new gateways, new software, and consistently integrating this new equipment and software into their existing infrastructure and processes. Typically, this approach is slow to implement and both difficult and expensive to maintain.
What is needed is a method and apparatus for inexpensively and flexibly inter-working in circuit, packet and circuit packet networks between one or more access protocols and one or more destination protocols.
It is an object of the current invention to provide an inexpensive and flexible method and apparatus for inter-working in circuit, packet and circuit packet networks between one or more access protocols and one or more destination protocols. By consolidating the inter-working logic in an Abstracted Common Call Control Inter-working Function (ACCCIF) that operates on abstracted signals and events, configuration and maintenance are simplified. At the same time, extending the invention by adding, updating or deleting protocols may be achieved quickly and consistently while the need to buy additional equipment in order to extend services is minimized.
In a preferred embodiment of the current invention, the ACCCIF is coupled to one or more protocol engines. The ACCCIF receives abstracted signals or events from one or more protocol engines and transmits abstracted signals or events to one or more protocol engines. In this configuration, the protocol engines may transform the signals, events and data that conform to a particular protocol into standardized, abstracted signals or events for processing by the ACCCIF. Similarly, the protocol engines may transform standardized, abstracted signals, events and data received from the ACCCIF into packets, cells, frames or signals compliant with a particular protocol for transmission.
In a preferred embodiment of the current invention, the ACCCIF may be implemented wholly or in part using a finite state machine.
Optionally, the invention may support local, remote, automated or manual configuration.
Advantageously, the current invention enables service providers to provide inexpensive, robust, extensible, comprehensive, integrated voice and data broadband services in a timely manner.